Internet of Threats - Parte II - 31/05/2023

2. Internet of Threats - Parte II

0. Resumen

Las redes denominadas Low Power Wide Area Networks (LPWAN) son tecnologías de comunicación inalámbrica que permiten la transferencia de datos entre dispositivos inalámbricos denominados nodos y estaciones base denominadas gateways. Estos equipos pueden estar separados por varios metros o incluso kilómetros y actualmente este tipo de redes son una alternativa popular en el mundo de la Internet de las Cosas debido a su eficiencia energética y a su amplio rango de aplicación. Al momento de elegir que tecnología LPWAN utilizar suelen tomarse en consideración tres puntos claves:

  1. El alcance o la distancia que hay entre nodo y gateway.

  2. El consumo energético que tiene cada protocolo de comunicación utilizado.

  3. La capacidad de transmisión de datos que tiene cada protocolo.

Ninguna de las tecnologías que utilizan las redes LPWAN cumplen a cabalidad con estos tres puntos ya que siempre habrá un compromiso entre ellas. Según el Dr. Italiano Massimo Merenda, investigador de la Universidad Mediterranea de Reggio en su publicación científica denominada Edge Machine Learning for AI-Enabled IoT Devices, o priorizas el consumo energético como lo hace el Bluetooth en desmedro de la velocidad de transmisión de datos o priorizas la transmisión de datos como es el caso del 4G en desmedro del consumo energético. El 4G tiene un excelente alcance y una gran tasa de transferencia, pero consume muchísima energía, lo que implica una batería más potente y un sin fin de otros requisitos.

Actualmente, existen tres grandes protocolos de comunicación en lo que se refiere a las tecnologías Low Power Wide Area Networks (LPWAN), estos son:

  - Sigfox: Diseñado para facilitar una comunicación eficiente con un bajo consumo de energía. Este protocolo asegura que con una carga mínima de batería, los nodos involucrados funcionen durante mucho tiempo. La red Sigfox permite la salida de datos a internet pero pagando una suscripción.

  - NB-IoT: Tiene la capacidad de conectarse sin problemas a redes móviles previamente establecidas ya que depende de la infraestructura de las compañías de telecomunicaciones para su despliegue. Mientras Sigfox ofrece una red global accesible para cualquier proyecto IoT, NB-IoT solo acepta proyectos lo suficientemente grandes como para que las compañías desplieguen una red dedicada.

  - LoRaWAN: LoRa es una tecnología de comunicación inalámbrica de banda ancha que funciona en todo el mundo, en Europa se implementa en los 868 MHz. LoRa se utiliza en proyectos donde el consumo de batería de los nodos debe reducirse al mínimo.

Tenga presente estimado lector(a) que si la red es local y no tiene salida a internet, la denominamos como LoRa, pero si los datos de los nodos salen a internet la llamamos LoRaWAN, por la red Wide Area Network.Inicialmente, la tecnología LoRa fue promovida por el fabricante de chips Semtech y actualmente está regida por LoRa Alliance, una organización sin fines de lucro creada para apoyar y promover la adopción global de este estándar. La asociación LoRa Alliance describe a las tecnologías LoRaWAN de la siguiente forma:

“un protocolo de red de baja potencia y área amplia (LPWA) diseñado para conectar de forma inalámbrica “cosas que funcionan con baterías” a Internet, tanto en redes regionales como nacionales o mundiales. Se enfoca principalmente en requisitos clave de la Internet de las Cosas como la comunicación bidireccional, la seguridad de extremo a extremo, la movilidad y los servicios de localización”.

A continuación una representación gráfica del stack de LoRa:

Si pones atención a la capa Media Access Control (MAC) Layer, notarás que existen tres clases de dispositivos, A, B y C. La inteligencia artificial de navegador Brave define estas clases de la siguiente manera:

Clase A: Dispositivos con máximo ahorro de energía lo que permite una autonomía prolongada de la batería. Solo envían datos cuando es necesario y después de enviar la información, esperan unos segundos antes de recibir datos del Gateway (puerta de enlace). Ideales para sensores de monitorización, como sensores de aparcamiento, que mandan una señal cuando están ocupados y otra cuando quedan libres.

Clase B: Dispositivos que pueden configurar el tiempo de recepción de mensajes, una vez pasado ese tiempo, pasan a modo de reposo. Adecuados para sensores y actuadores, como cuando se detecta el nivel de agua de un tanque y se manda la señal para cerrar la llave de entrada de agua. Necesitan recibir una baliza para la sincronización de tiempo desde la puerta de enlace LoRaWAN para determinar si todavía están en línea.

Clase C: Dispositivos que están activos constantemente, lo que requiere que estén conectados a una fuente de alimentación. Están diseñados para aplicaciones que requieren una respuesta rápida, como alumbrado o medidores eléctricos. Consumen más energía que los dispositivos de Clase A y B, lo que los hace menos adecuados para aplicaciones que requieren autonomía prolongada.

1. Red LoRaWAN en el edificio X

En algún lugar de la ciudad de Barcelona existe una red LoRaWAN trabajando a 868 MHz. Hay entre cuatro y cinco nodos conectados a esta red más dos gateways los cuales están separados por una distancia de aproximadamente un kilómetro. Los nodos tienen sensores incorporados los cuales recopilan datos ambientales como Dióxido de Carbono (CO2) y Compuestos Orgánicos Volátiles (VOC) con el fin de monitorear la calidad del aire en tiempo real. Esto es todo lo que te puedo contar sobre esta red. Más abajo, una fotografía que representa un dispositivo similar a los ocupados en esta red.

2. Los objetivos de esta investigación

Los objetivos de esta investigación tenían básicamente dos enfoques, uno de carácter práctico-experimental y otro enfoque de carácter teórico.

I. Utilizar el dongle RTL-SDR (Software Defined Radio) v4 y el software Radioconda (GNU Radio)para interceptar la señal LoRa emitida por los dispositivos involucrados y así descifrar las claves de activación-autenticación.

II. Reflexionar sobre aspectos más teóricos de este tipo de tecnologías, dejar volar la imaginación por un rato para comprender su funcionamiento y el alcance que tiene la Internet de las Cosas dentro de la sociedad moderna sobre todo de cara hacia los próximos años.

Para que no pierda su tiempo estimado lector(a), le anticipo desde ya que al menos el objetivo uno no logre llevarlo acabo, pero si esta interesado en el proceso, le suguiero que lea este post de todas formas.

3. La metodología de esta investigación

Había que estudiar el estado del arte de la IoT. Este trabajo era mi primera aproximación al mundo IoT desde una perspectiva academica y como era de esperarse la cantidad de información sobre estos temas es gigantesca dada la gran variedad de tecnologías involucradas. Entonces para cerrar el círculo, utilicé la información disponible únicamente entre los años 2022 y 2023. Este primer proceso me mostró una gran cantidad de incidentes de seguridad, bastante graves algunos, encontré también nuevas implementaciones de seguridad, diversos análisis sobre hardware utilizado en auditorías y nuevas técnicas de hacking ético aplicables al entorno IoT.

Se describen a continuación los pasos de esta metodología:

 1. Selección del caso y recopilación de datos

 2. Redefinición/ajuste de los objetivos

 3. Diseño experimental y su ejecución

 4. Análisis de resultados

 5. Conclusiones

4. Descripción de la arquitectura de la red

La arquitectura de la red LoRaWAN utilizada consta de varias secciones. Como ya podrán intuir ustedes, encontramos nodos y gateways, es decir, los dispositivos electrónicos encargados de monitorear la calidad del aire y la antena receptora que recibe todos esos datos y que funciona como puerta de enlace hacia internet. Encontramos también un clásico servidor de red cuya función es vital en esta red ya que proporciona autenticación y autorización a los dispositivos. Acá ya entramos en tierra derecha debido a que será este servidor de red el que compruebe que los dispositivos sean quienes dicen ser y otorgue la posterior autorización a la recepción de datos. Nos encontramos acá con el primer filtro de seguridad en la red.

Y finalmente como último eslabón de esta red tenemos la aplicación o software en internet la cual se utiliza para visualizar y almacenar todos los datos generados. En este caso, hablamos de una plataforma gratuita que permite a distintos usuarios integrar dispositivos IoT y establecer una conexión entre estos mismos.

Para ser bien claro, esta investigación solo se enfocó en tratar de analizar todo lo que abarca desde los nodos hasta el gateway que vendría siendo el espacio que ocupa el protocolo LoRa dentro de la red. Todo lo que viene después, es decir TCP/IP, no está considerado dentro de este post.

5. Seguridad en redes LoRaWAN

En lo que a seguridad se refiere, existen solo dos recursos asociados a la tecnología LoRaWAN: OTAA y ABP. Estos son los únicos dos métodos de activación-autenticación de dispositivos que tiene toda red LoRaWAN. Cada uno tiene sus propias características y consideraciones en términos de seguridad, flexibilidad y facilidad de implementación. La elección entre OTAA y ABP dependerá de los requisitos específicos del proyecto y las necesidades de seguridad de cada aplicación. Analicémoslos en detalle si les parece.

 • OTAA (Over-the-Air Activation)

Cuando se utiliza OTAA, hablamos de un nodo enviando un mensaje de solicitud de activación a una red LoRaWAN la cual a su vez responde con los parámetros de sesión necesarios para que el nodo en cuestión pueda unirse de manera segura. Estos parámetros incluyen tres cosas:

 - Un identificador de dispositivo único DevEUI

 - Un identificador de aplicación única AppEUI

 - Una clave de aplicación AppKey

El proceso OTAA proporciona una mayor seguridad y flexibilidad en la gestión de nodos ya que permite la generación dinámica de claves de sesión. En palabras más simples, cada vez que se inicie un proceso de autenticación, OTAA nos garantiza la creación de claves nuevas.

 • ABP (Activation by Personalization)

En lugar de solicitar y recibir parámetros de sesión dinámicamente como en el caso de OTAA, con ABP los parámetros de sesión se programan directamente en el dispositivo durante su fabricación y/o configuración inicial. Estos parámetros incluyen:

 - Un identificador de dispositivo único DevEUI

 - Una clave de red NwkSKey

 - Una clave de aplicación AppSKey

Una vez programados, el dispositivo podrá comunicarse con la red LoRaWAN utilizando estos parámetros predefinidos. ABP es más rápido y simple de implementar que OTAA, pero es menos seguro debido a la falta de generación dinámica de claves de sesión y la posibilidad de que las claves se vean comprometidas. El gran problema de esto es que, si yo como cibercriminal lograse descifrar la clave de un solo nodo, automáticamente todos los demás nodos que seán identicos se verían comprometidos pues compartiría datos similares.

Más detalles sobre este procedimiento en este artículo de la web techplayon.com. No lo analizo acá pues de lo contrario este post sería eterno.

5.1 Un pequeño dilema

Si la decisión dependiera del lector, ¿que método de activación utilizaría para su red LoRaWAN? ¿OTAA o ABP?

Lo lógico sería optar por la opción OTAA. Es muchísimo más seguro que las claves sean generadas constantemente antes que estas sean permanentes y además esten grabadas de forma fija en los dispositivos ¿cierto?. Bueno, lamentablemente no es tan simple. Los profesionales a cargo de estas redes tienen un dilema importante, tanto así que en algunos casos puede dejar a la seguridad como la última de las prioridades. Es necesario encontrar un balance entre tres principios, distancia (entre nodo y gateway), costo (de la instalación de la infraestructura) y energía (el consumo que harán los dispositivos).

Les presento un ejemplo. Es común encontrar dentro de una infraestructura LoRaWAN una gran cantidad de dispositivos instalados a una distancia considerable de la antena, esto significa que si por algún motivo se decidiera utilizar el método de autenticación OTAA en un dispositivo clase C, es decir, un dispositivo que esta permanentemente enviando solicitudes de autenticación y que además funciona las 24 horas del día, como por ejemplo un sensor que monitoreo de tráfico vehicular, el cambio de batería sería un procedimiento extremadamente complejo e ineficaz. Esto restaría uno de los puntos fuertes de el protocolo LoRa que es precisamente el ahorro del consumo energético. Elegir que método de activación utilizar en este contexto depende de la necesidad, no de la seguridad.

6. Desarrollo del Objetivo Práctico

I. Utilizar el dongle RTL-SDR v4 y el software Radioconda (GNU Radio)para interceptar la señal LoRa emitida por los dispositivos involucrados y así descifrar las claves de activación-autenticación.

El RTL-SDR v4 es un dongle USB que puede recibir señales de radio frecuencia sin la necesidad de usar internet. Dependiendo del modelo con el que se trabaje, podrás recibir frecuencias desde 500 kHz hasta los 1,75 GHz. La mayor parte del software compatible con RTL-SDR es gratuito. Si bien hay muchas copias del dongle dando vuelta por internet, en el sitio web del fabricante oficial rtl-sdr.com, en donde hay una guía que ayuda a reconocer el dispositivo original. Ojo con esto ya que el dispositivo original se calienta rápidamente a los 20 o 30 minutos de uso y aparentemente las copias de este dispositivo manejan de forma poco eficiente el calor lo cual dependiendo del clima podría ser peligroso.

Me tardé casi tres semanas en comprender como se utiliza el aparato y en conocer el software necesario para hacerlo funcionar. En el proceso, encontré dos artículos que me sirvieron como guía para entender las etapas que existen dentro de las auditorías de ciberseguridad IoT que utilizan tipo de dispositivos. El primero es “LoRaWAN Networks Susceptible to Hacking” por Cesar Cerrudo, CTO de la empresa IOActive y el segundo artículo es “Testing LoRa with SDR and some handy tools” por Sebastien Dudek. Dejo los links por si alguien quiere darles una mirada.

Etapa I: Reconocimiento

Con el software Magic SDR de Android hice un reconocimiento inicial, tanto de las instalaciones del edificio como del rango de cobertura de la señal. Con un adaptador USB a USBc pude conectar el dongle a mi teléfono y después de unos veinte minutos tratando de captar algo, logré encontrar en la frecuencia 863.300 una señal que se podía visualizar en el software como “partículas”. Inmediatamente me di cuenta de que era el nodo enviando datos a través de la señal ya que era idéntico a como lo había visto en algunos tutoriales en Youtube.

En la figura b en la parte azul del espectro se pueden apreciar una especie de “particulas” las cuales aparecían cada cierto intervalo de tiempo.

Etapa II: Aplicación

En esta etapa realicé el mismo ejercicio de la etapa I, pero esta vez utilizando el software SDR ++ para MacOS versión AMR. Quería descartar que la señal captada en la etapa anterior resultara ser un posible fallo de la app de Android u otra cosa. Como se puede observar en la figura de más abajo, el canal de la señal es exactamente el mismo 863.080.300 aunque ya no se aprecia en forma de “particulas” si no más bien como una línea vertical azul/celeste.

Sin más dilación, desenfundé el software Radioconda, nombre que recibe GNU Radio en la versión de Mac OS. Esta aplicación es extremadamente compleja de utilizar y requiere una gran pericia en lenguajes de programación como Python o C, pericia que de momento yo no tengo. Al momento de abrir la aplicación, verás un canvas “blanco”. Acá la idea es que el propio usuario cree un script en base a las opciones disponibles en la ventana de la derecha. Estas opciones son un subconjunto de bloques que al ser arrastrados con el mouse al espacio en blanco pueden conectarse con otros módulos formando así un flujo de trabajo. Estuve bastante lejos poder ocupar este software pero al menos alcancé a comprender que el flujo de trabajo necesario para conseguir el primer objetivo consistiría eventualmente en capturar, demodular, decodificar y entender la estructura de los paquetes los cuales describí anteriormente en el punto número cinco de este post. Cada uno de estos bloques, en este orden especifico y correctamente configurados, permitirían llevar a cabo la captura y posterior decodificación de señales LoRa.

Una pieza fundamental y que se debe agregar a este flujo es el bloque llamado GR Lora, el cual permite recibir mensajes modulados de radio LoRa utilizando SDR. Dejo acá el repositorio en GitHub por si lo llegas a necesitar.

El no haber podido completar el ejercicio práctico deja un sabor amargo considerando el enorme esfuerzo y la cantidad de tiempo dedicados a entender siquiera los fundamentos básicos de estas tecnologías. La complejidad técnica involucrada, sumada a mi limitada experiencia con herramientas avanzadas como Radioconda y también la necesidad de dominar lenguajes de programación como Python o C, resultaron ser barreras difíciles de superar en el tiempo disponible para este proyecto. Sin embargo, este proceso ha sido una valiosa puerta de entrada que, pese a los desafíos, me permitió adquirir un conocimiento significativo y despertar un particular interés en la materia.

Si quieres conocer el proceso en su totalidad, no dudes en leer el artículo que deje más arriba Testing LoRa with SDR and some handy tools.

7. Desarrollo del Objetivo Teórico

II. Reflexionar sobre aspectos más teóricos de este tipo de tecnologías, dejar volar la imaginación por un rato para comprender su funcionamiento y el alcance que tiene la Internet de las Cosas dentro de la sociedad moderna sobre todo de cara hacia los próximos años.

Como usted sabrá, en el paradigma actual del Internet de las Cosas (IoT) se ha observado un incremento significativo en la cantidad, variedad y en el tamaño del mercado. Muchas ciudades dependen cada vez más de dispositivos IoT en áreas clave como el transporte público, la infraestructura hospitalaria y, por supuesto, la industria. Sin embargo, desde un punto de vista técnico, existe un problema crítico que frena la evolución de la Internet de las Cosas: el hardware interno de estos dispositivos es insuficiente para manejar el gigantesto volumen de datos que estos mismos generan. Estos dispositivos, generalmente pequeños y diseñados para la producción en masa, están pensados más para ventas recurrentes que para ofrecer soluciones a largo plazo. Los fabricantes priorizan la obsolescencia programada y la renovación constante, dejando a los usuarios atrapados en un ciclo de reemplazo continuo ya que el soporte no suele durar más de dos años.

Por otro lado, soluciones como la computación en la nube no logran resolver este problema. En aplicaciones críticas, como las médicas, depender de la nube no es viable debido a la elevada latencia que podría generarse al procesar datos provenientes de un gran número de dispositivos conectados simultáneamente. ¿Que pasaría si tienes un dispositivo que esta midiendo los signos vitales de un paciente crítico?, esta información debe estar si o si en tiempo real, no puede presentar retraso alguno, de lo contrario sería peligroso. Entonces esta latencia, combinada a los costos asociados, limita la eficacia de las soluciones basadas en la nube.

Es aquí donde surge la necesidad de acercar los procesos de cómputo lo máximo posible a los dispositivos, dotándolos con una especie de ‘conciencia propia’. Los investigadores Massimo Merenda, Carlo Porcaro y Demetrio Iero exploran este concepto en su documento Edge Machine Learning for AI-Enabled IoT Devices, publicado el 29 de abril de 2020. Ellos describen cómo sería posible implementar esta idea mediante la combinación de tres recursos fundamentales del campo de la inteligencia artificial, recursos que tienen la particularidad ser altamente eficientes en el uso de la energía:

  - Support Vector Machine: Un algoritmo de aprendizaje supervisado utilizado principalmente para problemas de clasificación y regresión.

  - Deep Learning: Una rama del aprendizaje automático que utiliza redes neuronales profundas para identificar patrones y relaciones complejas en los datos.

  - Neural Networks: Modelos inspirados en el funcionamiento del cerebro humano, compuestos por neuronas artificiales interconectadas que procesan y analizan información de manera eficiente.

Este enfoque plantea un salto evolutivo considerable hacia lo que podríamos denominar como "the internet of conscious things", en donde los dispositivos IoT no solo recolectan y transmiten datos, sino que además procesan de manera inteligente y autónoma en tiempo real, reduciendo latencia y aumentando la eficiencia en el uso de batería.

7.1 ¿Ejecutar Algoritmos en Dispositivos IoT?

El pilar fundamental de esta propuesta radica en la capacidad de ejecutar algoritmos específicos en dispositivos con recursos limitados, como por ejemplo un microcontrolador Arduino. Aunque esto permite un procesamiento local de datos, persiste un desafío importante: eso sería la etapa inicial de aprendizaje de una red neuronal en Machine Learning. Esta etapa requiere recursos computacionales significativamente mayores. No obstante, la etapa de “inferencia” —posterior al aprendizaje automático— es mucho más ligera, ya que el modelo se limita a aplicar los cálculos previamente aprendidos para generar predicciones o tomar decisiones basadas en datos entrantes.

Un ejemplo destacado de esta viabilidad técnica se encuentra en el trabajo de investigación de Mallikarjun Anandhalli y Vishwanath P. Baligar titulado A Novel Approach in Real-Time Vehicle Detection and Tracking Using Raspberry Pi. En este estudio, realizado en el Departamento de Ciencias de la Computación e Ingeniería del BVB College of Engineering and Technology en India, se demuestra cómo algoritmos complejos pueden ejecutarse en hardware de recursos limitados.

El algoritmo desarrollado fue implementado en una Raspberry Pi 3 (ARMv8 de cuatro núcleos a 1.2 GHz y 1 GB de RAM) con una cámara integrada y utilizando la biblioteca OpenCV (Open Source Computer Vision Library). En este caso, se diseñó un sistema de reconocimiento facial en el que una cámara inalámbrica captura imágenes y las transfiere a la Raspberry Pi para su procesamiento. Este experimento confirma que es posible emplear microcontroladores en el contexto del aprendizaje automático, aunque aún queda por determinar cuáles algoritmos son los más adecuados para estos dispositivos.

Raspberry Pi 3 - Modelo B+ - 1.4GHz Cortex-A53 con 1GB RAM

Implementar técnicas de aprendizaje automático en dispositivos con recursos limitados no solo es factible, sino que ofrece ventajas significativas: reduce el embotellamiento de la red, mejora la eficiencia energética y preserva la privacidad al procesar los datos directamente en el dispositivo. Sin embargo, persiste la incertidumbre de si estas técnicas se consolidarán en los próximos años como un nuevo paradigma, especialmente en el ámbito de la fabricación masiva de dispositivos. A corto plazo, estas estrategias parecen más relevantes en contextos de redes pequeñas con un número reducido de nodos. Pensando en el futuro, es probable que sea necesario atravesar varias etapas de miniaturización de procesadores antes de dotar a estos dispositivos de un nivel limitado de “conciencia”.

8. Conclusión Crítica

Después de varios meses de trabajo, confieso una sensación de vacío respecto al conocimiento adquirido en esta área. El proceso de investigación resulta etéreo, carece de límites definidos y se dispersa fácilmente. De forma involuntaria, uno tiende a abrir constantemente nuevas líneas de exploración: un PDF lleva a un video, este a un artículo en un blog, y así sucesivamente, generando la sensación de que nunca se tiene información suficiente. Lo que esperaba que fuera un aprendizaje sólido terminó pareciendo una cocina desordenada llena de mierdas por limpiar.

Sin embargo, a pesar de este caos, puedo afirmar con convicción estimado lector(a) que una ciberseguridad eficiente, robusta y viable en el contexto de la Internet de las Cosas debe fundamentarse en las siguientes características:

1. Protección adecuada de las claves de cifrado.

2. Reemplazo inmediato de claves predeterminadas.

3. Uso de claves únicas por dispositivo y auditorías regulares de las claves raíz.

4. Implementación de módulos de seguridad de hardware (HSM) para prevenir la exposición de claves sensibles.

Estas medidas, combinadas con herramientas como firewalls, sistemas de detección y prevención de intrusiones (IDPS) y monitoreo en tiempo real, son esenciales para reforzar la seguridad.

Ahora bien, aunque estas recomendaciones suenen impecables en un discurso formal o en una entrevista de trabajo, la realidad es muy distinta. La ciberseguridad sigue siendo un campo desigual, dominado por monopolios tecnológicos y marcado por altos costos de implementación. Mientras que las certificaciones y capacitaciones en seguridad son prohibitivamente caras, las herramientas para cometer delitos cibernéticos suelen ser gratuitas y de fácil acceso. Este desequilibrio deja a gran parte del ecosistema vulnerable, dependiendo únicamente de quienes puedan costear su protección.

Una analogía histórica puede ilustrar esta dinámica: la Italia fragmentada de la Edad Media, donde las ciudades-estado competían ferozmente por poder y recursos, mientras los más débiles quedaban indefensos. De manera similar, el estado actual de la ciberseguridad se asemeja a un feudo en el que solo los mejor financiados pueden defenderse de los “forajidos digitales”.

Quizás, en el futuro, la automatización mediante inteligencia artificial logre democratizar la ciberseguridad, reduciendo costos y equilibrando el campo de juego. Por ahora, sin embargo, la iniciativa permanece en manos del enemigo, y mientras persista el afán por ampliar enfermizamente la superficie de ataque, no hacemos más que incorporar nuevas amenazas a nuestros sistemas.

9. Bibliografía

1. Edge Machine Learning for AI-Enabled IoT Devices

2. LoRaWAN

3. rtl-sdr.com

4. LoRaWAN Networks Susceptible to Hacking

5. Testing LoRa with SDR and some handy tools

6. techplayon.com

7. GitHub (GR LoRa)

8. A Novel Approach in Real-Time Vehicle Detection and Tracking Using Raspberry Pi

9. Raspberry Pi 3